This invention relates generally to object oriented software technologies and particularly to software objects which are binary compatible.
ActiveX controls are a subset of the COM object oriented software technology. COM can use a variety of different object oriented program languages such as C++, Java and Visual Basic. ActiveX controls are typically plugged into a control container which is a type of client.
The ActiveX controls self-register on a computer in a database. In Windows®-based platforms, the database is called a registry. The registry provides a way for a control to advise the client about the controls functionality. More specifically, the ActiveX control places keys in the registry or database to let the container know its functionality. The registry includes information which identifies a particular control or object including Globally Unique Identifiers (GUIDs), Category Identifiers (CATIDs), and Class Identifiers (CLSIDs).
A layer class, wrapper or interface definition is a source code level version of a COM object. It provides an interface between the container or client and the object which may be an ActiveX control. Additional controls may be inserted, snapped in or “plugged in” to a container that already has one or more controls. A plug-in control is source compatible if a new version of the control works unchanged in a container application but the user program must be rebuilt. That is, the application program must be recompiled and then the application can be run without further change.
With a “binary compatible” control, a new version can be plugged into an existing application that was designed and built for the old version. However, the conventional wisdom in the field is that the plug-in must appear to the container as if it were the old version in order for the plug-in to be binary compatible. That is, the plug-in must support the old CLSID and all interfaces exactly as they were (that is, with the same IIDs, names, dispids, parameters and so forth). See Denning, Adam, “ActiveX Controls Inside Out”, Microsoft Press (1997), p. 131. Thus, the conventional wisdom holds that in order to be binary compatible, the same identifiers and interfaces must be used for the plug-in.
A GUID is conventionally hard coded into a layer class. Other objects can then be used with a given container; however, they must have the same interface and GUID in order to work with the layer class in a binary compatible fashion.
Thus, there is a continuing need to enable objects, with different interfaces and/or different GUIDs, to snap in to a container or client environment.